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(54) Computer executing multiple operating system 

(57) A computer system having a plurality of operat- 
ing systems and a module for switching the operating 
systems in view of priorities of tasks to be performed by 
each of the operating systems. Each of the operating 
systems performing a plurality of processes or threads 
in accordance with the priorities assigned to these proc- 
esses or threads has a module for notifying the compu- 
ter system of the priority of the currently executing 
process or thread. The computer system includes a 
module for translating the priorities sent from each oper- 
ating system into priorities (normalized priorities) com- 
mon throughout the computer system, and a module for 
comparing the normalized priorities obtained by the pri- 
ority translation module in order to select and execute 
preferentially the operating system having a common 
priority higher than that of any other operating system. 
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Description 

[0001] The present invention relates to a computer 
executing any one of a plurality of operating systems 
being switched as needed and to a method for switching 
such operating systems. More particularly, the invention 
relates to a method for switching a plurality of operating 
systems each having a specif ic priority scheme. 
[0002] Heretofore, virtual machines (VM) have 
been known as a technique used by mainframes to run 
a plurality of operating systems on a single computer 
unit. According to the technique, a plurality of user tasks 
(processes and threads are generically called tasks 
hereunder) are executed while being switched on a plu- 
rality of virtual machines operating parallelly within the 
mainframe. A virtual machine is usually implemented as 
a process in the mainframe; a virtual machine may also 
be regarded as an operating system in view of its rela- 
tionship to user tasks. 

[0003] Generally, virtual machines are each 
assigned a predetermined time slice (allocated CPU 
time) in accordance with the priority of the virtual 
machine in question Each virtual machine switches and 
runs user tasks within the assigned time slice. A tech- 
nique for improving execution efficiency of such virtual 
machines is disclosed illustratively in JPA 5-197577. 
"Execution Priority Control System for Virtual 
Machines." 

[0004] The technique cited above involves a plural- 
ity of virtual machines and a virtual machine monitor for 
controlling the multiple virtual machines. On starting or 
ending the execution of a high priority task such as a 
system task, a virtual machine notifies the virtual 
machine monitor of the priority of the task in question. In 
response, the virtual machine monitor changes the exe- 
cution priority of the virtual machine in question to com- 
ply with the received priority. Where the execution 
priority of each virtual machine is changed to match the 
priority of the task to be performed thereby, control over 
virtual machines is said to be executed efficiently 
[0005] Meanwhile, improvements in the perform- 
ance of microcomputers, especially those for embedded 
uses, along with enhanced functionality of operating 
systems, have inspired a need in users to run and 
dynamically switch a plurality of operating systems con- 
currently on a single computer. 

[0006] In such applications as mechanical controls 
at factories and plants and car navigation systems, 
among others, emphasis is placed on a real-time 
response capability of responding to changes in the 
external environment in real time, as well as on high reli- 
ability that ensures long-time uninterrupted operation. 
For these reasons, many such applications adopt a real- 
time operating system (real-time OS) that is highly 
responsive to external changes and is compact and 
module-based in structure. However, while stressing the 
real-time responsiveness and reliability, the real-time 
OS tends to be short on amenities of human-oriented 



interface. 

[0007] By contrast, business-use operating sys- 
tems (business-use OS) installed in common personal 
computers (PC) have user-friendly interface features 

5 that typically permit image-based user manipulations. 
For that reason, there has been a growing need for uti- 
lizing the business-use OS in applications dominated by 
real-time OS's. However, because it primarily 
addresses interactive exchanges with human operators, 

10 the business-use OS stresses throughput rather than 
interrupt responsiveness. That is, under the business- 
use OS, processing may continue with interruptions 
inhibited for a relatively long time. The business-use OS 
is not as compact as the real-time OS in terms of struc- 

15 ture and consequently is less reliable. As such, the busi- 
ness-use OS is not fit for round-the-clock or other 
extended operations. 

[0008] Still, if a business-use OS and a real-time 
OS are run and switched as needed on a single compu- 

20 ter as in the case of multiple virtual machines (i.e., oper- 
ating systems) run on a mainframe, it is possible to take 
advance of the benefits of both systems: user-friendly 
interface on the one hand, and real-time responsive- 
ness and reliability on the other hand. Given today's 

25 enhanced performance of microcomputers, the scheme 
of running a plurality of operating systems on one com- 
puter unit is no longer an exclusive prerogative of main- 
frames. 

[0009] If the relevance of each operating system is 

30 taken into consideration, the simplest scheme of switch- 
ing multiple operating systems will involve having a real- 
time OS run most of the time and replaced by a busi- 
ness-use OS only when executable real-time OS tasks 
do not exist. However, there is no simple way of putting 

35 any one individual task above others in terms of priority 
(e.g., making real-time OS tasks always higher in prior- 
ity than business-use OS tasks). 
[0010] Fig. 27 shows an example demonstrating 
that simple classification of tasks in terms of priority is 

40 difficult to achieve. The figure illustrates a typical consti- 
tution of a simplified car navigation system assumed to 
be made up of four tasks: (1 ) a position recognition task 
370 for recognizing the driving position of the car; (2) a 
route searching task 371 for finding the shortest route to 

45 a destination; (3) an interface task 372 for processing 
inputs from buttons and touch panel controls of the sys- 
tem; and (4) a game task 373 started during a rest stop. 
The position recognition task and the route searching 
task generally demand quick response and high reliabil- 

so ity and are run by a real-time OS 1 1 1 , while a business- 
use OS 110 with its user-friendly interface carries out 
the interface task and game task. But route search gen- 
erally requires performing huge amounts of calcula- 
tions which may take as long as several seconds in a 

55 single pass. If tasks are simply classified as described 
above, then processing of the interface task is neces- 
sarily halted during the route search calculations and no 
key input effected repeatedly by the user will be recog- 
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nized during that period. 

[0011] The car navigation system shown in Fig. 27 
has a high priority assigned to the interface task. When 
that task is placed in an executable state, the business- 
use OS needs to be run preferentially. According to the 
above-cited conventional technique (for "Execution Pri- 
ority Control System for Virtual Machines"), however, it 
is assumed that all virtual machines (i.e., operating sys- 
tems) have the same functionality. In order to address 
changes in the environment, most real-time OS's gener- 
ally have a far larger number of priority levels than their 
business-use counterparts. Furthermore, the real-time 
and business-use OS's may have their priority levels 
arranged in a mutually opposite direction in an extreme 
case: the smaller the priority value (dose to "0"), the 
higher the priority for the real-time OS; the larger the pri- 
ority value, the higher the priority for the business-use 
OS. In that case, rf each of the two operating systems 
requests a virtual machine monitor for priority over the 
other, the virtual machine monitor will have difficulty 
determining which operating system to start preferen- 
tially. The conventional technique above is thus incapa- 
ble of controlling in a unified manner the business-use 
and real-time OS's each having conceptually different 
functions. 

[001 2] It is therefore an object of the present inven- 
tion to provide a computer having a multiple operating 
system controller for switching a plurality of different 
operating systems and selectively running one of them 
in consideration of the priorities of tasks to be per- 
formed by each operating system, whereby high-priority 
tasks are executed preferentially. 
[0013] In carrying out the invention and according 
to one aspect thereof, there is provided a computer for 
switching and running a plurality of operating systems 
which execute a plurality of tasks according to their pri- 
orities. The computer performs the following: 

(1) A priority monitoring process is carried out to 
monitor the priorities of tasks executed by the oper- 
ating systems involved. Alternatively, a priority noti- 
fication process may be implemented within each 
operating system for notification of the priority of the 
task currently performed thereby. However, some 
business-use or real-time OS's are incapable of 
additionally accommodating the priority notification 
process therein. It is in such cases that the priority 
monitoring process needs to be performed. 

(2) A priority translation process is carried out 
whereby that priority of the currently executing task 
which is acquired from each operating system is 
translated into a priority common to all operating 
systems involved (a common priority is called the 
normalized priority hereunder). 

(3) A priority comparison process is performed 
whereby the normalized priorities obtained by the 
priority translation process from each operating 
system are compared so that the operating system 



to be run preferentially is determined and switched 
to. 

[0014] According to the invention outlined above, 
5 the priority notification process is implemented within 
each operating system. Every time an operating system 
switches tasks, notification of the priority of the current 
task is provided by the process. 
[0015] A task switching function constitutes a core 
to of an operating system. For that reason, it is often diffi- 
cult to incorporate priority notifying means in commer- 
cially available operating systems. Still, the operating 
system generally has management information about 
an ongoing task held in computer memory, and part of 
is the management information includes task execution 
priorities. In order to enhance the speed of task switch- 
ing, the operating system may store the priority of the 
currently executing task in a specific variable (stored pri- 
ority variable). Taking advantage of these features, the 
20 priority monitoring process retrieves the task manage- 
ment information or stored priority variable to verify the 
priority of the task being carried out by each operating 
system. The priority monitoring process verifies task pri- 
orities by use of such timings as external interruptions 
25 and timer interruptions. 

[0016] The priority translation process involves 
translating the priority of the currently executing task 
obtained from each operating system into a normalized 
priority common to the operating systems involved 
30 within the computer. In implementing its function, the 
priority translation process may have a priority transla- 
tion table corresponding to each operating system. The 
priority translation table is a correspondence table 
allowing normalized priorities to be determined based 
35 on the task priorities specific to each operating system. 
Although it is possible to translate task priorities of indi- 
vidual operating systems into normalized priorities 
using simple numerical formulas, priority translation 
tables should preferably be used to switch the operating 
40 systems in a rapid and flexible fashion. For example, 
normalized priority values to be set into the priority 
translation tables may be defined in such a manner that 
the normalized priorities from the individual operating 
systems will not become identical to one another. 
45 [0017] The priority comparison process involves 
acquiring from the priority translation process the nor- 
malized priority of currently executing task priority of 
each operating system to see if any other operating sys- 
tem has a higher normalized priority than the currently 
so executing operating system. If an operating system with 
a higher normalized priority is detected, that operating 
system is selected to replace the current operating sys- 
tem. 

[0018] Other objects, features and advantages of 
55 the invention will become more apparent upon a read- 
ing of the following description and appended drawings. 
In the drawings: 
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Fig. 1 is a block diagram showing a typical system 
constitution of a computer practiced as a first 
embodiment of this invention; 
Fig. 2 is a block diagram depicting a hardware 
structure of the computer; 5 
Fig. 3 is a schematic view of a status register for 
use when an interrupt level mask function is pro- 
vided; 

Fig. 4 is a schematic view of a status register for 
use when an individual interrupt mask function is 10 
provided; 

Fig. 5 is a block diagram showing detailed internal 

structures of operating systems; 

Fig. 6 is a first block diagram depicting a detailed 

internal structure of an operating system switching is 

program; 

Fig. 7 is a flowchart of steps constituting a process 
flow of a reschedules 

Fig. 8 is a flowchart of steps constituting a process 

flow of a priority translation module; 20 

Fig. 9 is a flowchart of steps constituting a process 

flow of a priority comparison module; 

Fig. 10 is a second block diagram illustrating a 

detailed internal structure of the operating system 

switching program; 25 

Fig. 11 is a flowchart of steps constituting a process 

flow of an OS context switching module; 

Fig. 1 2 is a flowchart of steps constituting a process 

flow of a common interrupt handler; 

Fig. 1 3 is a flowchart of steps constituting a process 30 

flow of an interrupt handler; 

Fig. 1 4 is a flowchart of steps constituting a process 

flow of a lock acquisition module under a priority 

ceiling scheme; 

Fig. 1 5 is a flowchart of steps constituting a process 35 
flow of a lock release module under the priority ceil- 
ing scheme; 

Fig. 1 6 is a block diagram showing a detailed inter- 
nal structure of a priority setting module; 
Fig. 1 7 is a flowchart of steps constituting a process 40 
flow of a priority reverse translation function of the 
priority translation module; 

Fig. 1 8 is a flowchart of steps constituting a process 
flow of the priority setting module; 
Fig. 1 9 is a flowchart of steps constituting a process 45 
flow of the lock acquisition module under a priority 
inheriting scheme; 

Fig. 20 is a flowchart of steps constituting a process 
flow of the lock release module under the priority 
inheriting scheme; 50 
Fig. 21 is a block diagram depicting a detailed inter- 
nal structure of an interrupt mask level calculation 
module; 

Fig. 22 is a flowchart of steps constituting a process 
flow of the interrupt mask level calculation module; 55 
Fig. 23 is a block diagram showing a typical system 
constitution of a computer practiced as a second 
embodiment of this invention; 



Fig. 24 is a flowchart of steps constituting a process 
f tow of a priority monitoring module; 
Fig. 25 is a flowchart of steps constituting a process 
flow of the common interrupt handler that starts the 
priority monitoring module; 
Fig. 26 is a block diagram showing a typical system 
constitution of a computer practiced as a third 
embodiment of this invention; 
Fig. 27 is a schematic view illustrating how tasks 
are typically apportioned between operating sys- 
tems; 

Fig. 28 is a schematic view showing another struc- 
ture of the common interrupt handler; and 
Fig. 29 is a block diagram showing a typical system 
constitution of a computer practiced as a fourth 
embodiment of this invention. 

[0019] Preferred embodiments of this invention will 
now be described with reference to the accompanying 
drawings. 

[0020] Fig. 1 shows an overall constitution of a com- 
puter practiced as the first embodiment of this invention. 
The computer generally comprises a processor 100, a 
memory 101, an I/O controller 102, a disc drive 104, 
and a display 105. The processor 100, memory 101 and 
I/O controller 102 are interconnected by a processor 
bus 103. The processor 100 is implemented as a micro- 
processor that runs a plurality of operating systems. 
The memory 101 stores a business-use operating sys- 
tem (OS) 110, a real-time OS 111, tasks 112 through 
117 performed by the operating systems, and an oper- 
ating system switching program 1 18. These programs 
are read out and executed by the processor 100. 
[0021] The I/O controller 102 is connected to the 
disc drive 104 that stores programs and data, as well as 
to the display 105 that provides screen displays. Where 
a computer for factory and plant control purposes or for 
built-in uses is to be implemented, the I/O controller 102 
may be connected to a real-time control network 106. 
The real-time control network 106 is linked to such I/O 
devices as sensors and actuators. Any or all of the disc 
drive 104, display 105, and real-time control network 

106 may be omitted depending on the system configu- 
ration. The I/O controller 102 is connected to the proc- 
essor 100 through an interrupt signal line 107 and 
notifies the processor 100 of the completion of an I/O 
operation and other events. Although Fig. 1 shows the 
interrupt signal line 107 to be independent of the proc- 
essor bus 103 for purpose of illustration, the signal line 

107 is in fact an integral part of the bus 103. The proc- 
essor 100 incorporates a timer 108 that generates an 
internal interruption at constant intervals. Interruptions 
from the timer 1 08 are used for time management by the 
operating systems. 

[0022] The processor 100 is capable of masking 
external interruptions sent over the interrupt signal line 
107 or internal interruptions from the timer 108. Inter- 
rupt masking is a function for delaying specific interrup- 
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tions until the function is canceled by a program. 
Generally, three types of interrupt masking exist: 

(1) all-interrupt masking: all interruptions are 
masked. 5 

(2) individual interrupt masking: interruptions are 
masked individually. 

(3) interrupt level masking: levels are set for individ- 
ual interruptions so as to mask interruptions below 

a specified level. w 

[0023] In many cases, either the function types (1) 
and (2) or the function types (1) and (3) above are com- 
bined to implement the interrupt mask function. Which 
combination to adopt depends on the type of the proc- 15 
essor 100. If the processor 100 adopts the combination 
of the types (1) and (3), interrupt levels are determined 
in accordance with the importance of each I/O device 
handling interruptions. Illustratively, interruptions from 
the real-time control network 1 06 are set to be higher in 20 
priority than those from the disc drive 104 or display 
105. 

[0024] In the first embodiment, two operating sys- 
tems, i.e.. business-use OS 110 and real-time OS 111, 
reside in the computer. These operating systems utilize 25 
memory and processor resources assigned thereto in 
executing the tasks 112 through 114 as well as the 
tasks 115 through 117. It is assumed that the first 
embodiment comprises two operating systems and six 
tasks (three to each OS). However, this is not limitative 30 
of the invention, and more or fewer operating systems 
and/or tasks may be provided to practice the invention. 
Whereas the first embodiment does not presuppose 
dynamic changing of the number of operating systems, 
it is possible for the first embodiment to let each operat- 35 
ing system generate or delete tasks in a dynamic fash- 
ion. Although the description that follows will cover the 
business-use OS 110 and real-time OS 111, the tech- 
niques to be described below also apply to any other 
types of operating systems. The tasks 1 12 through 114 40 
are business-use tasks performed by the business-use 
OS, while the tasks 1 15 through 1 17 are real-time tasks 
carried out by the real-time OS. The tasks are defined in 
terms of priorities independently under each of the busi- 
ness-use OS 11 0 and real-time OS 1 1 1 . 45 
[0025] In the first embodiment of Fig. 1, the tasks 
112 through 1 14 have priorities 0, 7 and 31 respectively 
under the business-use OS 110; and the tasks 115 
through 117 have priorities 0, 99 and 255 respectively 
under the real-time OS 1 1 1 . For the first embodiment, it so 
is assumed that a task generically refers to a process or 
a thread. A process signifies a program that runs while 
occupying an individual memory space. Thus a given 
process cannot generally alter data of another program. 
A thread refers to a program that runs while sharing a 55 
common memory space of a process. That is, no data 
protection function exists between threads that operate 
within the same process. 



24 A2 8 

[0026] The operating systems incorporate priority 
notification modules 120 and 121. The priority notifica- 
tion module 120 or 121 is executed upon task switcho- 
ver of each operating system, notifying the operating 
system switching program 1 18 of the priority of the next 
task to be carried out. 

[0027] In many cases, the business-use OS has a 
priority scheme different from that of the real-time OS. 
The real-time OS generally has a relatively large 
number of priority levels to provide quick response to 
important interruptions. The business-use OS, on the 
other hand, adopts a relatively small number of priority 
levels to enhance throughput. For some operating sys- 
tems, the smaller the priority value (i.e., close to 0), the 
higher the priority; for other operating systems, the 
larger the priority value, the higher the priority. It follows 
that simply comparing priorities obtained illustratively by 
the priority notification modules 120 and 121 of the dif- 
ferent operating systems often has little significance. 
For purpose of explanation, it is assumed that the larger 
the priority value, the higher the task priority for the busi- 
ness-use OS 110 (task 114 has the highest priority in 
Fig. 1) and that the smaller the priority value, the higher 
the task priority for the real-time OS 11 1 (task 1 15 has 
the highest priority in Fig. 1). Priorities may be desig- 
nated anywhere between 0 and 31 for the business-use 
OS 110. and between 0 and 255 for the real-time OS 
111. 

[0028] The difference in priority scheme between 
the two operating systems is resolved as follows: the 
operating system switching program 118 has priority 
translation modules 122 and 123 as well as a priority 
comparison module 124 as its components. The priority 
translation modules 122 and 123 translate priorities 
coming from the business-use OS 1 10 and real-time OS 
111 respectively into normalized priorities that are com- 
mon throughout the system. Task priorities from the 
operating systems, not comparable while unmodified, 
can be compared once they are translated into normal- 
ized priorities. Normalized priorities can be identical to 
those of one of the operating systems involved. In that 
case, the operating system in question provides priori- 
ties that are regarded as normalized priorities. The pri- 
ority comparison module 124 compares normalized 
priorities obtained from both operating systems and 
switches to one of the operating systems that has the 
higher normalized priority of the two. 
[0029] Fig. 2 outlines an internal structure of the 
processor 100. A cache memory 131 is a buffer storage 
that temporarily stores data or instructions from the 
memory 101. A CPU 130 is an arithmetic circuit that 
reads instructions from the memory 101 or from the 
cache memory 131 and executes them one after 
another. In carrying out instructions, the CPU 130 uses 
a general register 132 that retains computed results 
temporarily, a program counter 133 that designates an 
instruction address, and a status register 134 that 
retains execution status. The CPU 1 30, cache memory 
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131, general register 132, program counter 133, and 
status register 134 are interconnected by a data bus 
1 36 and an address bus 1 37. The data bus 1 36 is made 
up of a plurality of signal lines for transferring data. The 
address bus 137 is constituted by a plurality of signal 
lines for designating addresses. 
[0030] The interrupt signal line 107 and timer 108 
are connected to an interrupt controller 135. The inter- 
rupt controller 135 generates an interrupt status signal 
138 indicating what kind of interruption is currently gen- 
erated to the processor 100. Generally, the status regis- 
ter 134 has information about the current interrupt mask 
and determines whether or not to accept the interrup- 
tion designated by the interrupt status signal 138. If the 
interruption is accepted, the interrupt controller 135 
updates the program counter 133 and status register 
134, and makes corresponding interrupt handler exe- 
cuted. 

[0031 ] Fig. 3 shows a structure of the status register 
1 34 for use when the processor 1 00 is provided with the 
all-interrupt masking function and interrupt level mask- 
ing function. In Fig. 3, the status register 134 comprises 
an interrupt block bit 140 and an interrupt mask level 
field 141. If the interrupt block bit 140 is turned on, all 
interruptions to the processor 100 are masked. The 
interrupt mask level field 1 41 denotes a current interrupt 
mask level value; interruptions below the denoted level 
are rejected. In Fig. 3. the interrupt mask level field 141 
is four bits long so that up to a total of 16 mask levels 
may be designated thereby. (In practice, 15 mask levels 
are specifiable because interrupt level 0 signifies that 
interrupt masking is suppressed.) Changing the bit 
count in the interrupt mask level field 141 allows the 
number of acceptable interrupt levels to be varied. 
[0032] Fig. 4 depicts a structure of the status regis- 
ter 1 34 for use when the processor 100 has the all-inter- 
rupt masking function and individual interrupt masking 
function. In this example, the status register 1 34 is actu- 
ally composed of two registers (i.e., execution status 
register 142 and interrupt mask register 143). As in the 
makeup of Fig. 3, the execution status register 142 con- 
tains an interrupt block bit 140. Interrupt mask bits 144 
through 147 in the interrupt mask register 143 corre- 
spond to different kinds of interruptions. When any one 
of the interrupt mask bits is turned on, the correspond- 
ing kind of interruption is not accepted. The status reg- 
ister of Fig. 3 is a specialized variation of the status 
register shown in Fig. 4. Illustratively, the state in which 
the interrupt mask bit 144 alone is turned on may be 
equated with level 1 ; the status in which the interrupt 
mask bits 144 and 145 are turned on, with level 2; the 
status where the interrupt mask bits 144 through 146 
turned on, with level 3; and so on. Thus in the descrip- 
tion that follows, the status register 134 is assumed to 
have the structure illustrated in Fig. 4. 
[0033] Generally, when the processor accepts an 
interruption, the interrupt block bit 140 is automatically 
turned on by hardware and the address of the interrupt 



handler is set to the program counter 133. The interrupt 
block bit 140 may be turned off as needed by the inter- 
rupt handler to permit servicing of the interruption. It is 
also possible for an operating system or a task to 
5 update temporarily the contents of the interrupt block bit 
140 or of the interrupt mask register 143 in order to 
make the servicing of a specific interruption waited. The 
interrupt masking function is used to effect exclusive 
control and to prevent generation of the same interrup- 
to tion during interrupt handling. 

[0034] Fig. 5 depicts interna! structures of the busi- 
ness-use OS 110 and real-time OS 111. In Fig. 5, all 
components of the operating systems are shown held in 
the memory 100. 
is [0035] Both the business-use OS 1 1 0 and the real- 
time OS 111 manage executable task information in the 
form of queues 150 and 151 . Although executable task 
queues 1 50 and 1 51 may be set up for each priority, the 
first embodiment gets each operating system to man- 
20 age all executable tasks in a single queue. The techni- 
cal contents of this invention are not affected by whether 
each OS has a single executable task queue or by 
whether each priority is matched with a queue. Each 
task takes three states successively: (a) an execution 
25 state, (b) an executable state, and (c) a wait state. For 
these reasons, each operating system supplements the 
executable task queue with other queues for managing 
such tasks as wait state tasks and stopped state tasks. 
The additional queues are omitted in Fig. 5. Task man- 
30 agement tables 1 60 through 1 65, controlled by the exe- 
cutable task queues 150 and 151, retain priorities of 
tasks to be executed as well as values of the program 
counter, status register and general register in effect 
upon task execution. 
35 [0036] Where executable tasks are managed by 
use of a single queue, the task management tables reg- 
istered to the queue are arranged in descending order 
of their priorities. That is, the management table of the 
next task to be executed is at the head of the queue. As 
40 described above, the business-use OS 110 has priori- 
ties 0 through 31 ; the larger the priority value, the higher 
the priority under this operating system. The real-time 
OS 1 1 1 has priorities 0 through 255; the smaller the pri- 
ority value, the higher the priority under this OS. Thus 
45 under the business-use OS 110, a task management 
table 162 corresponding to a task 114 (with priority 
value 31) comes at the head of the executable task 
queue 150, followed by a task management table 161 of 
a task 1 13 (with priority value 7) and a task manage- 
so ment table 1 60 of a task 1 1 2 (with priority value 0). Con- 
versely, under the real-time OS 111. a task 
management table 163 corresponding to a task 115 
(with priority value 0) comes at the head of the executa- 
ble task queue 151. followed by a task management 
55 table 1 64 of a task 1 16 (with priority value 99) and a task 
management table 1 65 of a task 1 1 7 (with priority value 
255). 

[0037] The operating systems also have interrupt 
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handlers 152 and 153 for performing interrupt handling, 
system call programs 156 and 157 for offering services 
to tasks, and reschedules 154 and 155 for switching 
tasks. The reschedulers 154 and 155 are started when 
tasks must be switched upon generation, deletion, stop s 
or resumption of a task or in the case of an external or 
internal interruption. The execution environment (e.g., 
register values) of the preceding task are placed into the 
corresponding task management table before the 
rescheduler 154 or 155 is called. When the next task to w 
be executed is determined, the execution environment 
relevant to the task in question is retrieved from the cor- 
responding task management table. The retrieved val- 
ues are set to the program counter, status register and 
general register so that the selected task is carried out. 75 
[0038] The reschedulers 1 54 and 1 55 have the pri- 
ority notification modules 120 and 121 inside. The prior- 
ity notification modules 120 and 121 are started 
immediately before the execution environment of the 
new task to be performed is set to the registers. When 20 
thus started, the priority notification module 120 or 121 
notifies the priority translation module 122 or 123 in the 
operating system switching program 1 18 of the priority 
of the task in question. 

[0039] Fig. 6 shows an internal structure of the 25 
operating system switching program 118. The priority 
translation modules 122 and 123 have priority transla- 
tion tables 170 and 171 for translating task priorities 
under the different operating systems into normalized 
priorities. With the first embodiment, normalized priori- 
ties are integers ranging from 0 to 255. For this embod- 
iment, it is assumed that the larger the normalized 
priority value, the higher the normalized priority. Natu- 
rally, it is also possible to alter the range of normalized 
priorities or to define that the smaller the normalized pri- 
ority value, the higher the normalized priority. 
[0040] As stated earlier, the business-use OS 1 10 
has priorities 0 through 31. In that case, the priority 
translation table 170 has an array of 32 entries. Each 
array element has an integer that falls anywhere 
between 0 and 255 and satisfies the following inequality 
(the array is named "prioBusiness"): 

i > j <z> prioBusiness [i] > prioBusiness [j] 
where, 0 ^ i and j ^ 31. 

[0041] The inequality above must be satisfied 
because the larger the priority value, the higher the pri- 
ority in the case of priorities under the business-use OS 
1 10 as well as for normalized priorities. 
[0042] Likewise, where the real-time OS 111 has 
priorities ranging from 0 to 255, the priority translation 
table 171 has an array of 256 entries. Each array ele- 
ment has an integer that falls anywhere between 0 and 
255 and satisfies the following inequality (the array is 
named "prio Realtime**): 

i > j prioRealtime [i] < prioRealtime Q] 
where, 0 = i and j = 255. 

[0043] The reason for having in the above inequality 
a less-than sign as opposed to a greater-than sign for 



the business-use OS is that the smaller the priority 
value, the higher the priority under the real-time OS. 
[0044] In Fig. 6, if the task 1 1 4 is judged to be exe- 
cutable next under the business-use OS 1 10, the prior- 
ity notification module 120 notifies the priority 
translation module 122 of the priority value of 31 . Using 
the priority translation table 170, the priority translation 
module 122 then acquires a normalized priority value of 
1 24. If the task 1 1 5 is judged to be executable under the 
real-time OS 111, the priority notification module 121 
notifies the priority translation module 123 of the real- 
time OS priority value of 0. By use of the priority trans- 
lation table 1 71 , the priority translation module 123 then 
obtains a normalized priority value of 255. It should be 
noted that for the first embodiment, the normalized pri- 
ority value from the business-use OS 110 never 
exceeds 124 no matter how high the task priority is 
under that OS. This is an extreme example of establish- 
ing priority translation tables in such a manner that real- 
time OS tasks are executed preferentially as much as 
possible. (A business-use OS task may take prece- 
dence over a real-time OS task if the latter has a lower 
priority.) Obviously, the priority translation table 1 70 may 
alternatively be modified in structure in such a manner 
that task priorities from the two operating systems are 
translated into normalized priorities on an equal basis 
as much as possible. 

[0045] Normalized priorities translated by the prior- 
ity translation modules 122 and 123 are sent to the pri- 
ority comparison module 124. The priority comparison 
module 124 holds a business-use OS normalized prior- 
ity 172 and a real-time OS normalized priority 173. In 
this case, the normalized priorities 1 72 and 173 take the 
values of 124 and 255 respectively. 
[0046] As described above, the priority notification 
modules 120 and 121 reside in the reschedulers and 
are each executed upon task switchover. Because only 
one task is performed between one task switchover and 
the next, the normalized priority under the operating 
system in question remains unchanged unless dynamic 
changing of task priorities is implemented. The priority 
notification modules 120 and 121 always provide notifi- 
cation of priorities upon task switchover. For that rea- 
son, the business-use OS normalized priority 172 and 
real-time OS normalized priority 173 held within the pri- 
ority comparison module 124 reflect the actual task pri- 
orities under the respective operating systems. 
[0047] The priority comparison module 124 com- 
pares the normalized priorities 172 and 173 from the 
two operating systems and allows one of the operating 
systems which has the higher priority to be executed 
preferentially In the example of Fig. 6, the real-time OS 
111 has the higher priority than the business-use OS 
110 and is thus executed in preference to the latter. 
[0048] In addition to the priority translation modules 
122 and 123 and the priority comparison module 124, 
the operating system switching program 118 includes a 
common interrupt handler 174 that apportions gener- 
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ated interruptions to the appropriate operating systems, 
an inter-OS communication function module 175 that 
ensures coordination of processing between the operat- 
ing systems, an OS context switching module 176 that 
switches the execution environments of the two operat- 
ing systems, and an interrupt mask level calculation 
module 177 that changes interrupt masks depending on 
the task priority. These programs will be described later 
in more detail. 

[0049] Fig. 7 is a flowchart of steps constituting a 
process flow of the rescheduler 1 54 under the business- 
use OS 110. The rescheduler 155 of the real-time OS 
111 is also constituted by like steps. The rescheduler 
154 is a module that is generally started after the regis- 
ter contents of the currently executing task are saved 
into the task management table when the current task 
has become no longer executable or when a task of a 
higher priority than that of the currently executing task 
has become executable, in any one of the following 
cases: 

(1) handling of a timer interruption has ended; 

(2) handling of an external interruption has ended; 
or 

(3) a system call is executed. 

System calls that can trigger activation of the resched- 
uler 154 include: 

(a) generation, termination, halt, or resumption of a 
task (e.g., when a task with a higher priority than 
the current task is generated); 

(b) execution or termination of exclusive control 
(e.g., when a task becomes a wait state upon an 
exclusive control.); and 

(c) changing of a task priority (e.g., when the prior- 
ity of the current task is reduced). 



[0050] The rescheduler 154 initially extracts the 
task management table of the highest priority from the 
executable task queue 150 (in step 181). At this point, 
an executable task may not exist, with all tasks in a wait 
state or stopped. Whether or not an executable task 
exists is judged in step 182. 

[0051] If there is no executable task, the resched- 
uler 154 notifies the priority translation module 122 of 
an idle state (in step 184). Because an executable task 
is absent, the idle loop is entered here (in step 186). The 
idle loop is a program that does nothing until a task to be 
performed appears. It should be noted here that the pri- 
ority translation module 1 22 is notified of the idle state in 
step 184. rf the business-use OS 1 10 is in an idle state, 
the priority comparison module 124 executes the real- 
time OS 1 1 1 in preference to the other OS. Thus unless 
both operating systems enter an idle state simultane- 
ously, the idle loop is not actually performed in step 186. 
When the business-use OS 1 10 is again executed, the 
idle loop is immediately left and step 181 is reached 



because there is a task to be performed. 
[0052] If an executable task is judged to exist in step 
182, the priority of the task to be performed next is 
extracted from the task management table and reported 
5 to the priority translation module 1 22. If the reported pri- 
ority is judged to be lower than the priority of the real- 
time OS 111 (by comparison of normalized priorities), 
then the real-time OS 111 is selected at that point. 
When the real-time OS 111 has higher normalized pri- 
10 ority than business-use OS 110, task execution is 
restarted immediately after step 183 unless the task to 
be performed becomes no longer executable because 
of an interruption or unless a task of a higher priority has 
become executable (i.e., the task selected in step 181 is 
is started). Naturally, if the currently executing task 
becomes no longer executable or if a task of a higher 
priority than the current task becomes executable, the 
rescheduler 154 is restarted. In step 185, the register 
contents are restored from the task management table 
20 and set to the registers of the processor 100. whereby 
the selected task is carried out. 

[0053] In the rescheduler 154, steps 183 and 184 
constitute processes done by the priority notification 
module 120. The priority notification module 121 is 
25 embedded likewise in the rescheduler 1 55. 

[0054] Fig. 8 is a flowchart of steps constituting a 
process flow of the priority translation module 122 cor- 
responding to the business-use OS 110. When called 
by the priority notif ication module 120, the priority trans- 
30 lation module 1 22 immediately performs priority transla- 
tion. First, the priority translation module 122 checks to 
see if the priority notification module 120 has reported 
an idle state (in step 190). The idle state may be 
regarded as a task with a priority lower than any other 
35 priority. In this example, the idle state is assumed to 
have a normalized priority value of -1 so that its priority 
is lower than any other normalized priority. In step 193. 
the value of -1 is sent to the priority comparison module 
124. If an idle state is not in effect, the corresponding 
40 entry is retrieved from the priority translation table 170 
(in step 1 91 ) and sent to the priority comparison module 
124 (in step 192). The same process flow applies to the 
priority translation module 123 corresponding to the 
real-time OS 111. 
45 [0055] Fig. 9 is a flowchart of steps constituting a 
process flow of the priority comparison module 124. 
First, the priority comparison module 124 checks to see 
if the received priority is a normalized priority coming 
from the business-use OS 1 10 or a normalized priority 
so from the real-time OS 1 1 1 (in step 200). If the received 
priority is judged to be a normalized priority of the busi- 
ness-use OS 110. the priority comparison module 124 
stores the acquired priority into a location of a business- 
use OS normalized priority 172 (in step 201). If the 
55 received priority is found to be a normalized priority of 
the real-time OS 111, the priority comparison module 
124 stores the obtained priority into a location of a real- 
time OS normalized priority 1 73 (in step 202). 
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[0056] A normalized priority is reported only if there 
is a possibility that the normalized priority of either oper- 
ating system may have been altered. In such a case, a 
comparison is made in value between the business-use 
OS normalized priority 172 and the real-time OS nor- 
malized priority 173 (in step 203). With the first embod- 
iment, an operating system having a larger normalized 
priority value than the other operating system is started 
preferentially. Thus if the normalized priority value of the 
business-use OS 11 0 is greater than the normalized pri- 
ority value of the real-time OS 111, the business-use 
OS 110 is selected as the operating system to be exe- 
cuted next (in step 204). Otherwise the real-time OS 
111 is performed next (in step 205). With the first 
embodiment, if the business-use OS 1 10 has the same 
normalized priority as the real-time OS 111, the real- 
time OS 111 is executed preferentially. Alternatively, 
arrangements may be made to let the business-use OS 
110 run in preference to the real-time OS 111 if they 
have the same normalized priority. One way to simplify 
the system structure is by making arrangements such 
that normalized priorities from both operating systems 
will not become identical in setting up contents of the 
priority translation tables 1 70 and 171. 
[0057] In step 206, a check is made to see if the 
operating system to be executed next is the same as the 
currently executing operating system. H the different 
operating system is to be executed next, the OS context 
switching module 1 76 is requested to save and restore 
the execution environments of the operating systems (in 
step 207). 

[0058] Fig. 10 shows detailed structures of the 
interrupt handlers 152 and 153. common interrupt han- 
dler 174, inter-OS communication function module 175, 
and OS context switching module 176 (the interrupt 
mask level calculation module 177 will be discussed in 
detail with reference to another figure). 
[0059] The interrupt handler 152 and 153 have 
interrupt stacks 214 and 215 as regions in which to save 
or temporarily retain variables such as register values in 
effect upon interruption. The register contents in effect 
immediately before an interruption must be saved, and 
must be restored after the interruption has been han- 
dled. The saving and the restoring of register values 
require the use of the interrupt stacks 214 and 215. A 
certain type of processor 100 is capable of automati- 
cally switching register contents upon interruption and 
of restoring the initial register values after the interrup- 
tion in question has been handled. In a computer per- 
mitting multiple interruptions, however, the use of such 
hardware still requires furnishing interrupt stacks (i.e., rf 
an interruption with a higher priority than the current one 
occurs during interrupt handling, the newly generated 
interruption needs to be serviced preferentially before 
handling of the initial interruption is resumed). 
[0060] The interrupt handlers 152 and 153 further 
possess interrupt stack pointers 216 and 21 7 pointing to 
the extent to which the respective interrupt stacks 214 



and 215 have been used. The interrupt handlers 152 
and 153 save the execution environment (e.g., register 
contents) in effect before an interruption and perform 
what is needed to handle the interruption using the 

5 interrupt stacks and interrupt stack pointers. At the end 
of the interrupt handling, the interrupt handlers 152 and 
153 restore the execution environment in effect before 
the execution in order to resume execution of the inter- 
rupted program. 

10 [0061] The common interrupt handler 174 appor- 
tions interruptions that may occur between the interrupt 
handlers 152 and 153. The common interrupt handler 
174 has a region that stores an executing OS stored 
variable 210 indicating whether the currently executing 

15 operating system is the business-use OS 110 or the 
real-time OS 111. Illustratively, if it is assumed that the 
business-use OS 1 1 0 is currently running in the setup of 
Fig. 10, the executing OS stored variable 210 contains 
data denoting "business-use OS." Obviously, storing a 

20 character string "business-use OS" in the executing OS 
stored variable 210 would be too inefficient. Instead, an 
integer storage scheme may be adopted illustratively to 
represent the business-use OS by "0" and the real-time 
OS by "1." The common interrupt handler 174 further 

25 includes an interrupt correspondence table 211 that 
indicates which operating system a given interruption 
corresponds to. That is, the interruption correspond- 
ence table 211 shows which operating system should 
handle any given individual interruption. As depicted in 

30 Fig. 4, there are 32 causes of interruption for the first 
embodiment. Thus the interrupt correspondence table 
211 is constituted by 32 entries (0 through 31). In the 
example of Fig. 10, each cause of interruption is defined 
as corresponding to a specific operating system: inter- 

35 rupt cause 0 corresponding to the business-use OS; 
interrupt cause 1, to the real-time OS; .... and interrupt 
cause 31, to the real-time OS. In order to promote effi- 
ciency, the contents of the interrupt correspondence 
table 21 1 should be retained likewise under the integer 

40 storage scheme as with the executing OS stored varia- 
ble 210, rather than under a character string storage 
scheme. 

[0062] A certain type of computer has any one of its 
I/O devices shared by two operating systems (e.g., 

45 when the business-use OS 110 and real-time OS 111 
both output characters and images on a single display). 
To implement such a system requires dynamic chang- 
ing of target operating systems for apportioned interrup- 
tions. It is for that reason that with the first embodiment, 

so the target operating system is not fixed but determined 
according to the interrupt correspondence table 211. 
Dynamic changing of target operating systems is imple- 
mented by modifying the contents of the interrupt corre- 
spondence table 21 1 depending on the use status of a 

55 given I/O device. 

[0063] By referring to the executing OS stored vari- 
able 21 0, the common interrupt handler 1 74 determines 
which operating system is currently running. If the cur- 



9 



EP 1031924A2_I_> 



17 



EP 1 031 924 A2 



18 



rently executing operating system is not the same as the 
target operating system identified from the interrupt cor- 
respondence table 211, the common interrupt handler 
174 requests the OS context switching module 176 to 
switch the operating systems. If the currently executing 
operating system is found to be the same as the target 
operating system, or if the operating systems have been 
switched, the interrupt handler of the applicable operat- 
ing system is requested to proceed with interrupt han- 
dling. The executing OS stored variable 210 is also 
referenced by the OS context switching module 176. As 
described, the internal structures of the modules within 
the operating system switching program 118 are not 
monopolized by individual modules but may be shared 
as needed between the modules. 
[0064] The OS context switching module 176 is 
started when there occurs a need to switch the operat- 
ing systems as a result of a comparison of priorities or 
upon generation of an interruption. In switching the two 
operating systems, the OS context switching module 
176 must have regions in which to save the execution 
environments of the operating systems (i.e., register 
values). The OS context switching module 176 is pro- 
vided with a region for a business-use OS saved context 
212 in which to save the execution environment of the 
business-use OS. and with a region for a real-time OS 
saved context 213 in which to save the execution envi- 
ronment of the real-time OS. The operating systems are 
switched by the OS context switching module 176 per- 
forming the following: save the execution environment 
into the saved context region for the currently executing 
operating system, retrieve the execution environment 
from the saved context region for the other operating 
system, and set the retrieved environment to the regis- 
ters of the processor 100. 

[0065] The inter-OS communication function mod- 
ule 175 is a program that ensures communication and 
coordination between tasks under the two operating 
systems. For the first embodiment, the inter-OS com- 
munication function module 175 includes a shared 
memory 21 8 that may be used by the business-use OS 
110 and real-time OS 111. Also included are a lock 
acquisition module 219 and a lock release module 220 
for effecting exclusive control between the operating 
systems. The shared memory 21 8 is part of the memory 
101 and may be referenced by both operating systems. 
The memory space other than the shared memory 218 
is roughly divided into a business-use OS area, a real- 
time OS area, and an operating system switching pro- 
gram area which are monopolized respectively by the 
business-use OS 1 10, real-time OS 1 1 1 , and operating 
system switching program 118. When tasks under the 
two operating systems use the shared memory 218. 
exclusive control is generally implemented to ensure 
data consistency in the shared memory 218. If an appli- 
cation program carries out exclusive control spanning 
the two operating systems, functions offered by the lock 
acquisition module 219 and lock release module 220 



10 



are utilized. 

[0066] Attention should be given to what is called a 
priority inversion phenomenon. This phenomenon gen- 
erally signifies the situation in which: 

(a) a task a of a low priority is first started, acquiring 
lock on memory; 

(b) a task p of a high priority is then started and 
enters a lock wait state; and 

(c) a task y of a medium priority is started, triggering 
a switchover from the task a (with the low priority) to 
the task y (with the medium priority). 



[0067] In the above situation, execution of the task y 
15 hampers execution of the task a and thereby prolongs 
the time it takes the high-priority task p to acquire lock. 
Such a priority inversion phenomenon is generally 
resolved by resorting to what is known as a priority ceil- 
ing scheme or a priority inheriting scheme. 
20 [0068] The priority ceiling scheme involves raising 
the priority of a task that has acquired lock to a prede- 
termined level. This makes the priority of the task a hav- 
ing acquired lock higher than that of the tasky (with the 
medium priority) on a temporary basis, allowing the task 
25 a to be performed continuously until lock is released 
even if the task y has been started. Thereafter, the high- 
priority task p acquires lock and the processing is con- 
tinued. 

[0069] The priority inheriting scheme is a variation 
30 of the priority ceiling scheme ensuring more flexibility 
than the original scheme. Under the priority inheriting 
scheme, if the task having entered a lock wait state 
(task p in the example above) has a higher priority than 
the task having acquired lock (task a), the higher priority 
35 is inherited by the lock-acquisition task. The task a 
inherits the priority of the task p only while lock is being 
acquired. In cases where exclusive control is effected 
between tasks of low priorities, it may not be necessary 
to raise the priority of a task that has acquired lock to a 
40 predetermined level. Such cases are dealt with effec- 
tively by the priority inheriting scheme. 
[0070] The lock acquisition module 219 and lock 
release module 220 of the first embodiment are pro- 
vided to implement the priority ceiling scheme or priority 
45 inheriting scheme between the operating systems. 
Either of the schemes is implemented by use of normal- 
ized priorities between the operating systems. 
[0071] What follows is a description of process 
flows of the OS context switching module 1 76, common 
50 interrupt handler 1 74, interrupt handler 152, lock acqui- 
sition module 219. and lock release module 220 shown 
in Fig. 10. The process flow of the interrupt handler 153 
is the same as that of the interrupt handler 1 52 and thus 
will be omitted from the ensuing description. 
55 [0072] Fig. 1 1 is a flowchart of steps constituting a 
process flow of the OS context switching module 176. 
The OS context switching module 176 is called only 
when the operating systems need to be switched; a 
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check on the need to effect such a switchover has been 
completed before the module 176 is called up. First, a 
check is made to see which operating system needs to 
be selected (in step 230). If the business-use OS 110 is 
to be replaced by the real-time OS 111 (i.e., the cur- 
rently executing operating system is the business-use 
OS 1 1 0 that needs to be taken over by the real-time OS 
1 1 1 with a higher priority than the other OS), the current 
values of the registers are saved into the business-use 
OS saved context 212 (in step 231). The execution envi- 
ronment is then retrieved from the real-time OS saved 
context 213 and set to the registers (in step 232). This 
allows the real-time OS 111 to be restarted from the 
state in which it was most recently halted upon saving of 
the register contents. Conversely, if the real-time OS 
111 is to be replaced by the business-use OS 110, the 
current values of the registers are saved into the real- 
time OS saved context 213 (in step 233), and the regis- 
ter values are restored from the business-use OS saved 
context 212 (in step 234). In any case, the value that 
shows the executing operating system following the 
switchover is written to the executing OS stored variable 
210 (m step 235). 

[0073] Fig 12 is a flowchart of steps constituting a 
process flow of the common interrupt handler 1 74. In a 
computer controlled by a single operating system, all 
interruptions are generally handled by a module called 
an interrupt handler before the interruptions are appor- 
tioned to individual programs. On the other hand, in a 
computer such as that of the first embodiment control- 
led by a plurality of operating systems, individual inter- 
rupt handlers are preceded by a common interrupt 
handler that initially receives all interruptions. The com- 
mon interrupt handler assigns the accepted interrup- 
tions to the interrupt handlers of the corresponding 
operating systems. When a given interruption is to be 
apportioned to an operating system, the currently exe- 
cuting operating system may not be the OS to which the 
interruption in question belongs. In that case, the oper- 
ating systems need to be switched; the switching is 
done by the common interrupt handler. 
[0074] After an interruption is generated, the com- 
mon interrupt handler 174 first retrieves the contents of 
the executing OS stored variable 210 and thereby deter- 
mines whether the currently executing operating system 
is the business-use OS 1 10 or the real-time OS 1 1 1 (in 
step 240). The interrupt correspondence table 211 is 
then used as a basis for determining the operating sys- 
tem to which the generated interruption corresponds (in 
step 241). For example, where the interrupt correspond- 
ence table 21 1 of Fig. 10 is used, an interruption "0" is 
judged to correspond to the business-use OS 110; an 
interruption "1." to the real-time OS 111; .... and an 
interruption "31 ," to the real-time OS 1 1 1 . Here, a check 
is made to see if the target operating system for the 
interruption is the same as the currently executing oper- 
ating system (in step 242). 

[0075] If the generated interruption is judged to be 



irrelevant to the currently executing operating system, 
the operating systems must be switched. The OS con- 
text switching module 176 is requested to carry out the 
switchover (in step 243). A check is then made to see 

5 whether the target operating system for the interruption 
is the business-use OS 1 10 or the real-time OS 1 1 1 (in 
step 244). If the target operating system turns out to be 
the business-use OS 110, the interrupt handler 152 of 
the business-use OS 1 10 is started (in step 245). If the 

to generated interruption corresponds to the real-time OS 
111, then the interrupt handler 1 53 of the real-time OS 
1 1 1 is started (in step 246). Generally, when a task 
switchover must be performed for interrupt handling, the 
interrupt handler 152 or 153 calls up the rescheduler 

75 154 or 155 and does not return control to the common 
interrupt handler 174. If a task switchover is not 
effected, the processing of the interrupt handler in effect 
is terminated then and there. At this point, the interrupt 
handler 152 or 153 returns control to the common inter- 

20 rupt handler 1 74 (to be described later with reference to 
Fig. 13). In turn, the common interrupt handler 174 
resumes processing from step 247. Step 247 is a step in 
which to verify whether the operating systems have 
been switched upon interrupt generation. If the operat- 
es ing systems were switched in step 243, they must be 
switched again to restore the initial execution environ- 
ment. The absence of switching of tasks signifies no 
change in the normalized priorities of the two operating 
systems. Hence the need for restoring the execution 

30 environment in effect before generation of the interrup- 
tion. Thus the OS context switching module 176 is again 
requested to carry out the switchover (in step 248). 
[0076] If the interrupt handler of either of the operat- 
ing systems has activated its rescheduler 154 or 155, 

35 control will not be returned to step 247 of the common 
interrupt handler 174 as described above. In such a 
case, the rescheduler 154 or 155 notifies the priority 
translation module 1 22 or 1 23 of a new task priority. The 
priority comparison module 124 then judges whether or 

40 not to switch the operating systems. 

[0077] The structure of the common interrupt han- 
dler 1 74 may be modified as shown in Fig. 28. The com- 
mon interrupt handler 174 depicted in Fig. 28 comprises 
an interrupt priority correspondence table 380 in addi- 

45 tion to the components of the common interrupt handler 
indicated in Fig. 10. The interrupt priority correspond- 
ence table 380 designates which interrupt handler 
should operate at which normalized priority level. In the 
example of Fig. 28, the interrupt handler corresponding 

50 to an interrupt cause 0 must operate at a normalized pri- 
ority level of 255. whereas the interrupt handler corre- 
sponding to an interrupt cause 31 must operate at a 
normalized priority level of 224. On starting the interrupt 
handler of a given operating system, the common inter- 
55 rupt handler 174 updates the normalized priority of the 
operating system in question according to the interrupt 
priority correspondence table 380. After terminating the 
interrupt handler, the common interrupt handler 174 
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restores the initial normalized priority. Although the 
common interrupt handler 1 74 is shown possessing the 
interrupt priority correspondence table 380 in this exam- 
ple, this is not limitative of the invention. Alternatively, 
the interrupt priority correspondence table 380 may be 
incorporated in each of the priority translation modules 
122 and 123 which are requested by the common inter- 
rupt handler 174 to translate priorities. 
[0078] If normalized priorities can be allocated to 
interruptions as shown in Fig. 28, then normalized prior- 
ities can also be assigned to all operation states of each 
operating system. Illustratively, an operation system 
generally has the following four operation states: 

(1) idle state 

(2) task execution state 

(3) self-processing state of the operating system 
(e.g., initialization) 

(4) interrupt handling state 

[0079] Normalized priorities may be allocated to all 
of the above operation states. In such cases, the inter- 
rupt handling state must generally be given the highest 
normalized priority to become active preferentially. The 
highest-priority interrupt handling state is followed by 
the serf-processing state of the operating system, the 
task execution state and the idle state, in that order. 
[0080] Fig. 13 is a flowchart of steps constituting a 
process fbw of that interrupt handler 152 in the busi- 
ness-use OS which is called up by the common inter- 
rupt handler 174. First, the interrupt handler 152 saves 
the current values of the registers into the interrupt 
stack 214 (in step 250), and handles the interruption in 
question (in step 251). A check is made (in step 252) to 
see rf the operating system is in a rescheduling state 
(i.e., to see whether the rescheduler 154 is being exe- 
cuted). The rescheduling state is a state in which the 
execution enveroment of previously executed task is 
saved on the corresponding task management table 
and the next task to be performed is being selected so 
that no task is currently executed. This means that if the 
processing of the operating system is to be simplified, 
rescheduling need only be executed from the beginning. 
That is, if a rescheduling state is detected, the saved 
register values in the interrupt stack are discarded (in 
step 257), and the rescheduler 154 is restarted (in step 
258). If an interruption is generated during reschedul- 
ing, it may not be necessary again to select the next 
task to be executed. In such a case, with the above 
method in use, rescheduling is still carried out from the 
beginning, which is not efficient. Such an inefficiency is 
averted illustratively by a method of queuing processes 
which occur during rescheduling and which may affect 
the execution of the rescheduler 154 (such as task acti- 
vation and termination). The queued processes are exe- 
cuted altogether before termination of the rescheduler 
154 or within the priority notification module 120. With 
the latter method in use. there is no need to restart 



partly-executed rescheduling every time an interruption 
is generated. However, after the queued processes are 
executed altogether, it is necessary to verify whether or 
not rescheduling is needed again. 
5 [0081] For purpose of simplification, the first 
embodiment is described as adopting the former of the 
two methods above. If the latter method is adopted, the 
following resources should be furnished: 



10 



(1) a flag indicating whether rescheduling is being 
carried out 

(2) a queue for acxx>mmodating processes 



[0082] In a system call or the other function pro- 

15 vided by the operating system, any process that may 
affect the execution of the rescheduler 154 is placed 
into the queue if rescheduling is under way. A module 
for performing the queued processes altogether is 
inserted into the process flow of the rescheduler 154. 

20 [0083] If the interrupt handler 152 judges that 
rescheduling is not under way, that means the operating 
system is currently performing some task. In that case, 
a check is made to see if tasks need to be switched (in 
step 253). If switching of tasks is judged to be unneces- 

25 sary (i.e., if the current task has the highest priority and 
is executable), the execution of the interrupt handler 1 52 
is terminated here. Then the register values saved in the 
interrupt stack 214 are restored (in step 254) and con- 
trol is returned to the common interrupt handler (in step 

30 255). If switching of tasks is judged to be necessary, the 
register values saved in the interrupt stack 21 4 are cop- 
ied to the task management table (in step 256), and the 
saved register values in the interrupt stack are dis- 
carded (in step 257). Thereafter the rescheduler 154 is 

35 started (in step 258). If the processor 100 is capable of 
referencing data in the memory 101 while changing the 
value on the interrupt stack pointer 216 at the same 
time, then steps 256 and 257 may be carried out collec- 
tively. 

40 [0084] Process flows of the lock acquisition module 
219 and lock release module 220 will now be described, 
rt is assumed that the modules are subject to the priority 
ceiling scheme; an embodiment relevant to a priority 
inheriting scheme will be described later. In the descrip- 

45 tion that follows, a task that has requested acquisition or 
release of lock is called the current task, and the operat- 
ing system managing that task is called the current 
operating system as opposed to the other operating 
system. 

so [0085] Fig. 14 is a flowchart of steps constituting a 
process flow of the lock acquisition module 219 under 
the priority ceiling scheme. The lock acquisition module 
219 first checks to see if a task of the other operating 
system has acquired lock (in step 260). If no task of the 

55 other operating system is judged to have acquired lock, 
the current operating system is set to be the lock holder 
(in step 261). rf any task of the other operating system 
has acquired lock, then the task of the current operating 
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system is placed in a wait state (in step 263). In that 
case, the other operating system must be allowed to run 
preferentially so that its task will release lock as soon as 
possible. This is accomplished by raising the normal- 
ized priority of the other operating system, stored in the 5 
priority comparison module 124, to a level higher than 
the normalized priority of the current operating system 
(in step 262). Placing the task into a wait state in step 
263 causes the current operating system to start the 
rescheduler. In turn, the rescheduler calls up succes- 70 
sively the priority notification module, priority translation 
module and priority comparison module, whereby the 
current operating system is replaced by the other oper- 
ating system whose normalized priority has been ele- 
vated. 15 
[0086] Fig. 15 is a flowchart of steps constituting a 
process flow of the lock release module 220 under the 
priority ceiling scheme. The lock release module 220 
first releases the lock it holds (in step 270). A check is 
then made to see if the other operating system is wait- 20 
ing to acquire lock (in step 271). If the other operating 
system does not wait for lock acquisition, the normal- 
ized priority has not be raised, and the execution of the 
lock release module 220 is terminated here. If the other 
operating system is waiting to acquire lock, the raising 25 
of a normalized priority should have been done to 
resolve the so-called priority inversion phenomenon. On 
that assumption, the initial normalized priority of the cur- 
rent operating system is restored (in step 272), and the 
task waiting to acquire lock is placed into an executable 30 
state (in step 273). Upon switching of tasks after the 
task waiting to acquire lock is made executable, the 
rescheduler of the other operating system is started. As 
with the lock acquisition module, the priority comparison 
module 124 is eventually executed. Then the operating 35 
systems are compared in terms of their initial normal- 
ized priorities, whereby the operating system with the 
higher priority of the two is selected. 
[0087] Described below is an example in which the 
priority inheriting scheme is implemented. In this case, 40 
as shown in Fig. 16, the operating systems involved 
must be provided with priority setting modules 280 and 
281 for changing task priorities in accordance with nor- 
malized priorities. In addition to the function of translat- 
ing priorities into normalized priorities, the priority 45 
translation modules 122 and 123 must comprise a func- 
tion of translating normalized priorities back to OS-spe- 
cific priorities. For that purpose, the priority translation 
modules 122 and 123 possess priority reverse transla- 
tion tables 282 and 283 wherein normalized priorities so 
are indexed to priorities specific to the individual operat- 
ing systems. 

[0088] For a system call, an operating system gen- 
erally has the ability to change task priorities. The prior- 
ity setting modules 280 and 281 translate received 55 
normalized priorities into priorities specific to the 
respective operating systems, changing task priorities 
by use of a task priority change system call. The priority 



reverse translation tables 282 and 283 functionally sup- 
port the priority setting modules 280 and 281 . Because 
the normalized priorities range from 0 to 255 in the first 
embodiment, the priority reverse translation tables 282 
and 283 have an array of 256 entries each. Since the 
priorities for the business-use OS 1 10 range from 0 to 
31 , each array element in the priority reverse translation 
table 282 has an integer that falls between 0 and 31 and 
satisfies the following inequality (the array is named 
"revBusiness"): 

i > j revBusiness p] 1= revBusiness Q] 
where, 0 ^ i and j ^ 255. 

[0089] The priorities for the real-time OS 1 1 1 range 
from 0 to 255. The smaller the priority value, the higher 
the priority for the real-time OS 1 1 1 . For these reasons, 
each array element in the priority reverse translation 
table 283 has an integer that falls between 0 and 255 
and satisfies the following inequality (the array is named 
"revReartime"): 

i > j => revReartime [i] ^ revReartime D] 
where, 0 - and j ^ 255. 

[0090] In the first embodiment, the normalized pri- 
orities range from 0 to 255 and the priorities specific to 
the real-time OS also range from 0 to 255. This makes 
it possible to provide one-for-one correspondence 
between the normalized priorities and the real-time OS 
priorities. It follows that the priority reverse translation 
table 283 can be derived uniquely from the priority 
translation table 171. On the other hand, the priority 
reverse translation table 282 cannot be determined 
uniquely because the priorities for the business-use OS 
range from 0 to 31 . In the latter case, the business-use 
OS priority corresponding illustratively to a normalized 
priority of "1 " cannot be derived from the priority transla- 
tion table 1 70. With respect to such normalized priori- 
ties that cannot be determined uniquely, the priorities of 
the business-use OS are suitably established to satisfy 
the inequality indicated above. 

[0091] Fig. 17 is a flowchart of steps constituting a 
process flow of the priority reverse translation function 
provided by the priority translation module 122. The 
business-use OS priority corresponding to a designated 
normalized priority is retrieved from the priority reverse 
translation table 282 (in step 290), and sent to the prior- 
ity setting module 280 (in step 291). The priority transla- 
tion module 123 provides a similar priority reverse 
translation function. 

[0092] Fig. 18 is a flowchart of steps constituting a 
process flow of the priority setting module 280. The pri- 
ority setting module 280 first requests the priority trans- 
lation module 1 22 to translate a normalized priority into 
a business-use OS priority (in step 292). Using a priority 
change system call of the business-use OS, the priority 
setting module 280 changes the priority of the task in 
question (in step 293). The priority setting module 281 
for the real-time OS 1 1 1 carries out similar processing. 
[0093] Described below is how to implement a typi- 
cal priority inheriting scheme through the use of the pri- 
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ority reverse translation functions and priority setting 
modules discussed above. 

[0094] Fig. 19 is a flowchart of steps constituting a 
process flow of the lock acquisition module 219 subject 
to the priority inheriting scheme. The lock acquisition 
module 219 first checks to see if another task has 
acquired lock (in step 300). If no other task is judged to 
have acquired lock, the lock acquisition module 219 
sets the current task as a lock holder (in step 301). If 
another task is judged to have acquired lock, the current 
task needs to be placed in a wait state until lock is 
released (in step 304). In that case, the lock-acquisition 
task must be executed preferentially so that the lock will 
be released as soon as possible. A comparison is made 
between the normalized priority of the lock-acquisition 
task and that of the current task (in step 302). If the lock- 
acquisition task is judged to have a lower normalized 
priority than the current task, the lock acquisition mod- 
ule 219 causes the lock-acquisition task to inherit the 
priority of the current task (in step 303). The inheriting of 
a priority is accomplished by requesting the priority set- 
ting module of the operating system running the lock- 
acquisition task to proceed with the priority setting proc- 
ess, with the normalized priority of the current task des- 
ignated If the lock-acquisition task is judged to have a 
higher normalized priority than the current task, there is 
no need for the priority to be inherited. The task is then 
placed immediately into a wait state. 
[0095] Fig. 20 is a flowchart of steps constituting a 
process flow of the lock release module 220 under the 
priority inheriting scheme. The lock release module 220 
first releases the lock it holds (in step 310). A check is 
then made to see if another task is waiting to acquire 
lock (in step 31 1 ). If no other task waits for lock acquisi- 
tion, that means the normalized priority has not been 
inherited, and the execution of the lock release module 
220 is terminated here. If another task is waiting to 
acquire lock, that means the normalized priority must 
have been inherited. On that assumption, the priority 
setting module is requested to restore the initial normal- 
ized priority of the current task (in step 312). The task 
watting to acquire lock is then placed into an executable 
state (in step 313). 

[0096] Although no specific description has been 
given in this specification, there may occur an inconsist- 
ency in the data denoting the lock holder if an interrup- 
tion generated during execution of the lock acquisition 
module 219 or lock release module 220 has led to the 
switching of tasks. Such contingency should be avoided 
by performing the interrupt masking function during the 
lock acquisition or release process. 
[0097] A viable priority inheriting scheme can be 
implemented under exclusive control between the oper- 
ating systems through the use of program modules and 
process flows depicted in Figs. 16 through 20. In prac- 
tice, the use of the process flows of Figs. 19 and 20 
makes it possible to inherit normalized priorities under a 
single operating system. 



[0098] Fig. 21 shows an internal structure of the 
interrupt mask level calculation module 177. The mod- 
ule 177 provides the function of translating a normalized 
priority into an interrupt mask level and masking an 

5 interruption if its translated level turns out to be higher 
than a predetermined level. This function is based on 
the concept that a task whose normalized priority is 
higher than a predetermined level must be executed in 
preference to interruptions. Even without this function, 

io the computer works pretty well provided it is capable of 
masking interruptions by resorting to system calls other 
function. Still, the interrupt mask level calculation mod- 
ule 177 offers the advantage of automatically effecting 
interrupt masking whenever the normalized priority 

is exceeds a predetermined value. 

[0099] The interrupt mask level calculation module 
177 has an interrupt mask translation table 320 for exe- 
cuting interrupt masking. The interrupt mask translation 
table 320 is used to translate normalized priorities into 

20 interrupt mask values. As shown in Fig. 4, the first 
embodiment is applicable to a computer architecture 
capable of individually masking 32 causes of interrup- 
tions. For that reason, each entry in the interrupt mask 
translation table 320 accommodates data 32 bits long. 

25 However, if the four-bit interrupt mask level of Fig. 3 is 
employed, each entry in the interrupt mask translation 
table 320 may be reduced to four bits in length. In the 
example of Fig. 21. the interrupt mask value corre- 
sponding to the normalized priority of w 0" is 0x00000000 

30 while the interrupt mask value corresponding to the nor- 
malized priority of "255" is Oxffffffff. This means that if 
the normalized priority is "0," then all interruptions are 
permitted and that if the system is operating with the 
highest normalized priority, then all interruptions are 

35 masked. The necessary masking of interruptions is car- 
ried out automatically when the priority comparison 
module 124 notifies the interrupt mask level calculation 
module 177 of the normalized priority of the currently 
executing operating system. 

40 [0100] Fig. 22 is a flowchart of steps constituting a 
process f tow of the interrupt mask level calculation mod- 
ule 177. First, the module 177 extracts the interrupt 
mask value corresponding to a designated normalized 
priority from the interrupt mask translation table 320 (in 

45 step 330). The interrupt mask value thus acquired is set 
illustratively to the interrupt mask register 143, and 
interrupt masking is executed (in step 331). 
[0101] The first embodiment of this invention has 
been described so far. As discussed, the first embodi- 

50 merit allows the operating systems to be switched in 
keeping with the priority of the task being carried out 
under each operating system. This embodiment 
involves incorporating the priority notification module in 
each of the existing operating systems so that the latter 

55 will provide notification of changed priorities every time 
rescheduling is carried out. However, many of today's 
commercially available operating systems are not ger- 
mane to such modifications. Such cases may be dealt 



14 



BNSDOCID: <EP 1031924A2_I_> 



27 



EP 1 031 924 A2 



28 



with by a second embodiment of the invention which is 
proposed and discussed below. 
[0102] Fig. 23 is a block diagram showing a typical 
constitution of a computer practiced as the second 
embodiment of this invention. It is assumed that the 
business-use OS 1 1 0 and real-time OS 1 1 1 hold the pri- 
orities of their currently executing tasks (execution prior- 
ities 340 and 341). That is. under the operating 
systems, the task management tables 162 and 163 
heading the executable task queues 150 and 151 
shown in FIG. 5 hold the execution priorities 340 and 
341 respectively. If a plurality of executable task queues 
are assigned to each priority, there is often provided a 
pointer or a variable; the pointer points to the location of 
the executable task queue having the highest priority at 
a given point in time, or the variable (priority-holding var- 
iable) indicates the value of the highest priority in ques- 
tion. If the pointer is provided, the execution priorities 
340 and 341 are obtained by retracing the executable 
task queue from the pointer to the task management 
table for reference thereto; rf the variable is provided, 
the execution priorities 340 and 341 are acquired by 
retrieving the priority-holding variable in question. 
[0103] A priority monitoring module 344 is incorpo- 
rated anew in the operating system switching program 
118. The rest of the modules in the operating system 
switching program 1 18, i.e., the priority translation mod- 
ules 122 and 123, priority comparison module 124, 
common interrupt handler 174, inter-OS communication 
function module 175, OS context switching module 176 
and interrupt mask level calculation module 177, have 
the same structures and process flows that were dis- 
cussed above in connection with the first embodiment. 
There is no priority notification module 120 or 1 21 in any 
of the operating systems. 

[0104] The priority monitoring module 344 retains a 
business-use OS execution priority stored value 342 
and a real-time OS execution priority stored value 343. 
Started periodically, the priority monitoring module 344 
monitors the execution priorities 340 and 341 of the 
respective operating systems. H the stored execution 
priority 342 or 343 is found to differ from the current exe- 
cution priority 340 or 341 , a change in the priority is rec- 
ognized. The priority translation module 122 or 123 is 
then notified of the new execution priority. 
[0105] Fig. 24 is a flowchart of steps constituting a 
process flow of the priority monitoring module 344. The 
priority monitoring module 344 first reads out the execu- 
tion priority 340 of the business-use OS for comparison 
with the business-use OS execution priority stored 
value 342 (in step 350). This step is intended to verify 
whether or not the priority of the business-use OS has 
changed. If the priority of the business-use OS has not 
changed, nothing is carried out and step 353 is 
reached. If a change in the priority is recognized, the 
execution priority 340 of the business-use OS is set to 
the business-use OS execution priority stored value 342 
(in step 351). and the priority in question is reported to 



the priority translation module 122 of the business-use 
OS (in step 352). The same process is carried out on a 
possible change in the priority of the real-time OS 111. 
That is, the execution priority 341 of the real-time OS is 

5 compared with its execution priority stored value 343 (in 
step 353). If no change is detected in the priority, the 
process is terminated. If a change in the priority is 
detected, the execution priority 341 of the real-time OS 
is set to the real-time OS execution priority stored value 

io 343 (in step 354). The priority in question is then 
reported to the priority translation module 123 of the 
real-time OS (in step 355). 

[0106] It should be noted that after the operating 
systems have been switched upon notification of the pri- 

15 ority to the priority translation module, control is 
returned to the begining of the priority monitoring mod- 
ule 344. In that respect, the monitoring method of Fig. 
24 is regarded as one which keeps monitoring priority 
changes of the business-use OS preferentially. If it is 

20 desired to monitor priorities of both operating systems 
on an equal basis, it is necessary to provide illustratively 
a modified process flow in which the number of times 
the priority monitoring module 344 is started is counted 
so that: 

25 

(1) if the module start count is an odd number, the 
priority of the business-use OS 1 1 0 is monitored for 
change; and 

(2) if the module start count is an even number, the 
30 priority of the real-time OS 111 is monitored for 

change. 

[01 07] It should be noted that the priority monitoring 
module 344 is started "periodically" to monitor priority 

35 changes. In order to implement periodical monitoring, 
the priority monitoring module 344 need only be started 
by timer interruptions. Because all interruptions includ- 
ing timer interruptions and external interruptions are 
handled collectively by the common interrupt handler 

40 1 74, the priority monitoring module 344 may be incorpo- 
rated in the common interrupt handler 174. This 
arrangement is described below. Fig. 25 is a flowchart 
of steps constituting a process flow of the common 
interrupt handler 1 74 incorporating the priority monitor- 

45 ing module 344. In Fig. 25, steps 240 through 248 are 
the same as their counterparts in Fig. 12. Starting the 
priority monitoring module 344 (in step 360) can trigger 
switching of the operating systems. For that reason, the 
monitoring of priorities must be effected downstream of 

so the execution of an interrupt handler (step 245 or 246). 
When the interrupt handler 152 or 153 returns control to 
the common interrupt handler 174, the monitoring on 
priority changes is automatically started. The operating 
systems are switched as needed. When the priority 

55 monitoring module 344 judges that there is no need to 
switch the operating systems, the processing of the 
common interrupt handler 174 is terminated. 
[0108] The second embodiment of this invention 
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has no means for notifying the priority translation mod- 
ule of any priority change that may take place immedi- 
ately after rescheduling. Because priority changes are 
checked at constant intervals, the operating systems 
are not switched immediately in response to a change in 
the priority. For this reason, the second embodiment 
constitutes a computer which requires no internal mod- 
ifications in its operating systems but which is subject to 
a reduced level of switching efficiency compared with 
the first embodiment. 

[0109] The second embodiment satisfies the 
requirement that both operating systems be left unmodi- 
fied internally. Alternatively, there may be a situation 
where the real-time OS 111 is ready for such internal 
modifications but the business-use OS 1 10 is not. That 
situation may be addressed by a third embodiment of 
the invention wherein the real-time OS 1 1 1 incorporates 
the priority notification module 121, with the priority 
monitoring module 344 monitoring only priority changes 
of the business-use OS 1 10 (Fig. 26). 
[0110] As another alternative, the priority notifica- 
tion module may be built not into the reschedules but 
into periodically activated components such as a timer 
interrupt handling module in each operating system. 
The arrangement substitutes for the priority monitoring 
module 344. 

[0111] When any of the above-described embodi- 
ments is applied to a car navigation system shown in 
Fig. 27, inputs from the user can be accepted even dur- 
ing a time-consuming operation of a route searching 
task in the system. In the setup of Fig. 27, an interface 
task is assigned a higher normalized priority than the 
route searching task. The push of a button by the user 
to start the interface task replaces the real-time OS with 
the business-use OS executing the task of the higher 
normalized priority. As a result the interface task is car- 
ried out even while the route searching task subject to a 
prolonged processing time is operating. 
[0112] There are virtual computers each compris- 
ing a plurality of operating systems. Applying this inven- 
tion to any one of such computer systems makes it 
possible to run its multiple operating systems having dif- 
ferent priority schemes in accordance with the priorities 
of their tasks to be carried out. 

[0113] The inventive arrangements discussed 
above combine to make up a computer that concur- 
rently offers advantages of two different operating sys- 
tems: the user interface of the business-use OS, and 
high reliability of the real-time OS. 
[0114] Each of the first through the third embodi- 
ments above of the invention is structured to translate 
priorities within the operating system switching program 
118. Alternatively, the priority translation modules 122 
and 123, which correspond respectively to the busi- 
ness-use OS 110 and real-time OS 111, may be built 
into these operating systems. A fourth embodiment of 
the invention shown in Fig. 29 is designed to accommo- 
date such modifications. 



[0115] In the fourth embodiment, the priority trans- 
lation modules 122 and 123 translate the priorities of 
both operating systems into normalized priorities. In 
turn, the priority notification modules 120 and 121 notify 
5 the priority comparison module 1 24 of the resulting nor- 
malized priorities representing the operating systems. 
[0116] In the fourth embodiment, all interfaces 
between the business-use OS 110 and real-time OS 
111 on the one hand and the operating system switch- 
re ing program 118 on the other hand are effected in 
accordance with normalized priorities. Each of the first 
through the third embodiments above provides notifica- 
tion of the priority of a task when that task is an execut- 
able one, and reports an idle state if there is no 
is executable task. Such idle states as well as self- 
processing states of the operating systems cannot be 
mapped freely in the order of normalized priorities rep- 
resentative of the states. With the fourth embodiment, 
by contrast, priorities are translated into normalized pri- 
ze orities under each operating system. That is, those 
states other than the state of task execution can be 
mapped freely in the order of their normalized priorities. 
[0117] As described and according to the invention, 
a computer with a single processor running a plurality of 
25 operating systems allows these operating systems to be 
switched according to the priorities of tasks executed 
thereby so that tasks of higher priorities are always car- 
ried out ahead of those of lower priorities. According to 
the invention, the operating systems are compared in 
30 terms of priorities by their priority translation modules 
translating task priorities into normalized priorities. Thus 
real-time responsiveness and efficiency are preserved 
for a computer that runs a plurality of operating systems 
subject to different priority schemes. 
35 [0118] As many apparently different embodiments 
of this invention may be made without departing from 
the spirit and scope thereof, it is to be understood that 
the invention is not limited to the specific embodiments 
thereof except as defined in the appended claims. 

40 

Claims 

1 . A computer comprising : 

45 a memory for storing a plurality of operating 

systems and a plurality of processes or threads 
to be performed by each of said operating sys- 
tems; and 

a processor for executing said operating sys- 
50 terns in accordance with priorities assigned to 

said processes or threads; 
wherein said processor retrieves the priorities 
of processes or threads to be performed by any 
one of said operating systems, translates the 
55 retrieved priorities into priorities common to 

said plurality of operating systems, selects the 
operating system to be executed in accordance 
with the priorities resulting from the translation, 
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and executes the selected operating system. 

2. A computer according to claim 1, wherein said 
memory comprises a priority translation table in 
which to map into the common priorities the priori- s 
ties of the processes or threads to be performed by 
said operating systems, and wherein said proces- 
sor selects the operating system to be executed on 
the basis of said priority translation table. 

10 

3. A computer according to claim 1 or 2, wherein said 
processor determines priorities specific to each of 
said plurality of operating systems on the basis of 
the priorities common to said operating systems, 
thereby changing the priorities of said plurality of is 
processes or threads to be performed by each of 
said operating systems. 



translating priorities of processes or threads to 
be performed by each of said operating sys- 
tems into priorities common to said plurality of 
operating systems; and 

comparing the common priorities obtained by 
the priority translating step in order to select 
and execute preferentially the operating sys- 
tem having a common priority higher than that 
of any other operating system. 

8. An operating system execution method according 
to claim 7, wherein said priority translating step, in 
translating priorities specific to each of said operat- 
ing systems into common priorities, translates the 
priorities of different operating systems into com- 
mon priorities that differ between said different 
operating systems. 



4. A computer according to claim 3, wherein said 
memory comprises a priority reverse translation 20 
table in which to map said common priorities into 
the priorities specific to each of sad operating sys- 
tems, and wherein said processor changes the pri- 
orities of said plurality of processes or threads on 
the basis of said priority reverse translation table. 25 

5. A computer according to any one of claims 1 
through 4, wherein, if a process or a thread is des- 
ignated for execution, said processor elevates the 
priority of the operating system in charge of carry- 30 
ing out the designated process or thread, the proc- 
essor further lowering the priority of the operating 
system in question when said designated process 

or thread is terminated in execution. 

35 

6. A data storage medium accommodating: 

a plurality of processes or threads; 
a plurality of operating systems for performing 
said plurality of processes or threads and pro- 40 
viding notification of a priority of a currently 
executing process or thread; 
a priority translating step of translating priori- 
ties sent from any one of said operating sys- 
tems into priorities common to said plurality of 45 
operating systems; and 
a priority comparing step of comparing the 
common priorities obtained by said priority 
translating step in order to select and execute 
preferentially the operating system having a so 
common priority higher than that of any other 
operating system. 



9. An operating system execution method according 
to claim 7 or 8, wherein said priority translating 
step, besides translating priorities of processes or 
threads to be performed by each of said operating 
systems into the common priorities, translates at 
least an interrupt handling state, a serf-processing 
state of any operating system, and an idle state into 
common priorities. 

10. A computer system having a plurality of operating 
systems and switching means for switching said 
plurality of operating systems, each of said operat- 
ing systems performing a plurality of processes or 
threads in accordance with priorities assigned to 
said processes or threads: 

wherein each of said plurality of operating systems 
further comprises priority translating means for 
translating the priorities of said processes or 
threads performed by the respective operating sys- 
tems into priorities that are common throughout 
said computer system, and priority notifying means 
for notifying said switching means of the common 
priorities obtained by said priority translating 
means; and 

wherein said switching means further comprises 
priority comparing means for comparing the com- 
mon priorities sent from each of said operating sys- 
tems in order to select and execute preferentially 
the operating system having a common priority 
higher than that of any other operating system. 



7. An operating system execution method for selec- 
tively executing any one of a plurality of operating ss 
systems, said operating system execution method 
comprising the steps of: 



17 
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